알람 피로를 줄이는 임계값 설계

목차

• #알림이 많을수록 안전하다는 착각
• #Page Ticket Log를 구분한다
• #원인보다 사용자 증상에 먼저 알린다
• #고정 임곗값이 자주 실패하는 이유
• #지속 시간과 Hysteresis로 흔들림을 줄인다
• #비율에는 표본 수 조건이 필요하다
• #SLO Error Budget과 Burn Rate
• #다중 시간 구간으로 빠른 장애와 느린 장애를 잡는다
• #중복 알림은 그룹화하고 하위 원인은 억제한다
• #Missing Data를 정상으로 취급하지 않는다
• #재구성한 Prometheus 알림 규칙 예제
• #알림 메시지에 필요한 정보
• #알림 품질을 지표로 관리한다
• #기존 알림을 정리하는 절차
• #마무리
• #참고 자료
• #관련 노트

알림이 많을수록 안전하다는 착각

처음 서비스를 운영하면 “혹시 모르니 알림을 하나 더 만들자”는 방향으로 가기 쉽다.

CPU > 70%
Memory > 75%
Disk > 80%
HTTP 500 count > 0
p99 > 1s
Pod restart count > 0

각 조건은 개별적으로 그럴듯하다. 하지만 트래픽이 순간 증가하거나 배포로 pod가 교체될 때 여러 알림이 동시에 울린다. on-call 담당자는 알림을 확인하고 대시보드를 열지만 대부분 자동으로 회복된다. 이 과정이 반복되면 알림을 즉시 확인할 이유가 약해진다.

진짜 장애가 왔을 때도 같은 채널과 소리로 수십 개 알림이 쏟아진다.

flowchart LR
    A[작은 지표 변동] --> B[낮은 품질의 page]
    B --> C[확인 후 행동 없음]
    C --> D[알림 신뢰 하락]
    D --> E[확인 지연 또는 무시]
    E --> F[실제 장애 MTTR 증가]

알람 피로는 개인의 집중력 문제가 아니라 시스템 설계 문제다. 사람이 모든 신호를 매번 해석하도록 두었기 때문에 생긴다.

답이 “내일 확인해도 된다”라면 ticket이고, “나중에 분석할 자료다”라면 dashboard나 log다. 답이 “할 수 있는 일이 없다”라면 자동 복구나 시스템 설계를 먼저 고쳐야 한다.

Page Ticket Log를 구분한다

모니터링 출력은 긴급도와 행동 시점에 따라 구분할 수 있다.

예를 들어 디스크가 6개월 뒤 가득 찰 추세라면 새벽 page가 아니라 capacity ticket이다. 반면 2시간 안에 가득 차 서비스가 중단될 것으로 예측되면 즉시 대응 후보가 된다.

disk free < 20%

단순 잔여 비율보다 소진 속도와 예상 시간을 함께 본다.

predict_linear(
  node_filesystem_avail_bytes{mountpoint="/data"}[6h],
  4 * 60 * 60
) < 0

위 식은 최근 6시간 추세가 이어질 경우 4시간 안에 여유 공간이 0 아래가 되는지 보는 개념 예시다. 파일 시스템의 비선형 증가, 정기 정리 작업, 예약 공간을 반영하려면 서비스에 맞게 보완해야 한다.

같은 지표도 시간에 따라 출력 종류가 달라질 수 있다.

30일 뒤 용량 고갈 → capacity ticket
4시간 뒤 용량 고갈 → urgent ticket 또는 page
현재 write 실패     → page

severity label만 붙이는 것으로 끝내지 않고 각 수준이 실제로 다른 전달 경로와 응답 기대 시간을 가져야 한다.

원인보다 사용자 증상에 먼저 알린다

CPU 90%, pod restart, replica lag는 원인 후보다. 사용자가 실제로 실패하는지는 별개의 문제다.

flowchart TD
    A[사용자 오류율 증가] --> B{어느 서비스인가}
    B --> C[API p99 증가]
    C --> D[DB pool 대기 증가]
    D --> E[특정 replica 지연]

첫 page는 사용자 오류율이나 SLO 위반처럼 가장 바깥 증상에서 울리는 편이 좋다. 하위 지표는 대시보드와 진단 정보로 제공한다. 그렇지 않으면 replica 하나가 자동 교체되는 동안 pod down, replica unavailable, service capacity low, API latency high가 모두 별도 page가 된다.

물론 모든 원인 알림이 나쁜 것은 아니다. 사용자 영향이 발생하기 전에 반드시 개입해야 하고 자동화할 수 없는 사건이라면 예방 page가 필요할 수 있다.

예방 page 후보
- 인증서가 2시간 안에 만료되고 자동 갱신이 실패함
- quorum 상실까지 노드 한 대만 남음
- 데이터 손실 위험이 있는 replication 중단
- 짧은 시간 안에 고갈될 저장 공간

기준은 “원인인가 증상인가”라는 분류 자체보다 즉각적인 인간 행동이 필요한가다.

RED 지표로 사용자 증상을 시작하는 방법은 RED Method로 API 모니터링 시작하기에서 정리했다.

고정 임곗값이 자주 실패하는 이유

다음 규칙은 단순하다.

alert: HighApiLatency
expr: api_request_duration_p99_seconds > 1

하지만 서비스의 정상 범위가 시간과 트래픽에 따라 달라질 수 있다.

• 밤에는 요청이 10건뿐이라 p99가 한 요청에 흔들린다.
• batch endpoint는 정상적으로 2초가 걸린다.
• 배포 직후 cold start 몇 건이 1초를 넘는다.
• 트래픽이 급증하면 900ms도 위험한 포화 신호일 수 있다.
• p99가 2초여도 SLO 대상이 아닌 내부 경로일 수 있다.

고정 임곗값은 이해하기 쉽고 예측 가능하다는 장점이 있다. 문제는 맥락 없이 전 서비스에 같은 값을 복사하는 것이다.

임곗값을 정할 때 다음 축을 함께 본다.

과거 데이터의 p95를 임곗값으로 그대로 쓰는 것도 주의한다. 과거 상태가 올바른 목표라는 보장이 없고, 장애 기간이 baseline에 섞이면 잘못된 정상 범위를 만든다. 사용자 기대와 SLO를 먼저 정의하고 과거 분포는 현실성 검증에 사용한다.

지속 시간과 Hysteresis로 흔들림을 줄인다

지표가 임곗값 주변을 오르내리면 알림이 firing과 resolved를 반복한다.

error rate
1.9% → 2.1% → 1.8% → 2.2% → 1.7%

threshold = 2%

Prometheus의 for는 조건이 일정 시간 연속으로 참일 때만 firing 상태로 바꾼다.

groups:
  - name: api-alerts
    rules:
      - alert: ApiErrorRatioHigh
        expr: service:http_error_ratio:rate5m > 0.02
        for: 10m
        labels:
          severity: page

이 규칙은 평가 순간 한 번 2%를 넘었다고 바로 울리지 않는다. 10분 동안 계속 조건을 만족해야 한다.

for 시간을 무조건 길게 잡으면 탐지가 늦어진다.

100% 실패가 10분 지속된 뒤 page
→ 이미 큰 사용자 피해 발생

영향이 큰 급격한 장애에는 짧은 창과 높은 임곗값을, 낮지만 지속적인 퇴행에는 긴 창과 낮은 임곗값을 사용할 수 있다. 이 아이디어는 뒤의 다중 구간 burn-rate alert로 연결된다.

알림이 해제되는 조건에도 완충이 필요하다. keep_firing_for를 지원하는 Prometheus 버전에서는 조건이 잠깐 해소되어도 일정 시간 firing을 유지해 flapping과 데이터 누락에 따른 가짜 resolve를 줄일 수 있다.

      - alert: ApiErrorRatioHigh
        expr: service:http_error_ratio:rate5m > 0.02
        for: 10m
        keep_firing_for: 5m

별도의 상·하한을 사용하는 hysteresis도 가능하다.

fire when error ratio > 2.0%
resolve when error ratio < 1.0% for 10m

모니터링 시스템이 상태형 조건을 직접 지원하지 않으면 recording rule과 alert state를 조합한다. 다만 너무 긴 해제 지연은 이미 복구된 장애가 계속 진행 중인 것처럼 보여 incident 종료를 늦출 수 있다.

비율에는 표본 수 조건이 필요하다

오류율 50%라는 숫자만 보면 심각해 보인다.

Case A: 1 error / 2 requests       = 50%
Case B: 50,000 errors / 100,000 requests = 50%

두 경우의 사용자 영향과 통계적 안정성은 다르다. 낮은 트래픽에서는 비율과 절대 건수 또는 요청률 조건을 함께 사용한다.

(
  sum(rate(http_server_requests_total{outcome="failure"}[10m]))
  /
  sum(rate(http_server_requests_total[10m]))
  > 0.02
)
and
(
  sum(increase(http_server_requests_total[10m])) > 500
)

위 값은 설명을 위한 예시다. 실제 최소 표본 수는 트래픽과 허용 가능한 누락 위험에 맞춘다.

절대 오류 수만 사용해도 문제가 있다.

10 errors/min

100 requests/min 서비스  → 10% 오류
100,000 requests/min 서비스 → 0.01% 오류

따라서 비율은 규모에 독립적인 품질을, 절대 수는 실제 영향을 보여 준다. 둘 중 하나만 쓰지 않고 목적에 맞게 결합한다.

높은 백분위수 알림도 같은 문제를 가진다. p99의 표본 수와 히스토그램 해석은 운영 지표에서 평균보다 백분위수를 보는 이유에서 자세히 다뤘다.

SLO Error Budget과 Burn Rate

고정 오류율보다 사용자 약속과 직접 연결된 기준이 SLO다.

SLO = 30일 동안 유효 요청의 99.9%가 성공
error budget = 1 - 0.999 = 0.001 = 0.1%

Burn rate는 허용된 오류 budget을 현재 속도로 얼마나 빠르게 소비하는지를 나타낸다.

burn rate
  = observed bad event ratio
  / allowed bad event ratio

SLO가 99.9%이고 최근 오류율이 2%라면 다음과 같다.

allowed error ratio = 0.1%
observed error ratio = 2%

burn rate = 2% / 0.1% = 20

20배 속도로 budget을 태우고 있다는 뜻이다. 이 속도가 30일 내내 지속되면 30일 budget을 1.5일 만에 소진한다.

time to exhaust budget
  = SLO window / burn rate
  = 30 days / 20
  = 1.5 days

이 접근의 장점은 서로 다른 목표를 가진 서비스에 같은 의미의 기준을 적용할 수 있다는 것이다.

관측 오류율은 같지만 API A는 budget을 10배로 태우고, API B는 목표와 같은 속도다.

다중 시간 구간으로 빠른 장애와 느린 장애를 잡는다

짧은 시간 창은 급격한 장애를 빨리 잡지만 순간 spike에 민감하다. 긴 창은 안정적이지만 탐지가 늦다.

5분 창  → 빠른 탐지, 높은 변동
1시간 창 → 지속성 확인, 느린 해제
6시간 창 → 완만한 budget 소모 탐지

Multi-window, multi-burn-rate alert는 긴 창과 짧은 창이 모두 기준을 넘을 때 울린다.

급격한 장애:
  1시간 burn rate > 14.4
  AND 5분 burn rate > 14.4

완만한 장애:
  6시간 burn rate > 6
  AND 30분 burn rate > 6

숫자는 30일 SLO window를 가정한 널리 쓰이는 설계 예시이지 모든 서비스의 정답이 아니다. 14.4배가 1시간 지속되면 30일 budget의 약 2%를 소비한다.

consumed budget fraction
  = burn rate × alert window / SLO window
  = 14.4 × 1 hour / 720 hours
  = 0.02
  = 2%

긴 창은 실제로 budget을 의미 있게 소비하고 있음을 확인하고, 짧은 창은 문제가 지금도 계속되는지 확인한다. 긴 창만 사용하면 이미 복구된 장애로 늦게 page할 수 있다.

flowchart TD
    A[bad event ratio 계산] --> B[긴 창 burn rate]
    A --> C[짧은 창 burn rate]
    B --> D{긴 창이 기준 초과?}
    C --> E{짧은 창도 기준 초과?}
    D -- 예 --> F
    E -- 예 --> F[Page]
    D -- 아니오 --> G[Dashboard 또는 관찰]
    E -- 아니오 --> G

낮은 트래픽 SLO에서는 burn rate도 표본 부족에 흔들릴 수 있다. 최소 이벤트 수, synthetic check, calendar-aligned SLO 계산 방식 등을 함께 검토한다.

중복 알림은 그룹화하고 하위 원인은 억제한다

장애 하나가 여러 인스턴스와 서비스에 영향을 주면 label set마다 알림이 따로 생성될 수 있다.

ApiErrorRatioHigh{instance="api-1"}
ApiErrorRatioHigh{instance="api-2"}
ApiErrorRatioHigh{instance="api-3"}

사용자 관점에서 하나의 서비스 장애라면 instance별 page 대신 service와 region으로 집계한다. 인스턴스 정보는 대시보드에서 확인한다.

Alertmanager 같은 전달 계층에서는 관련 알림을 그룹화한다.

route:
  group_by:
    - alertname
    - service
    - region
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

• group_wait: 연관 알림이 함께 도착할 시간을 기다린다.
• group_interval: 같은 그룹의 새 변화 전송 간격을 정한다.
• repeat_interval: 계속 firing인 알림을 다시 알리는 간격이다.

너무 긴 group_wait는 중요한 장애 탐지를 늦추고 너무 짧으면 묶이지 않은 알림이 연속으로 온다.

억제(inhibition)는 상위 장애가 울릴 때 예상되는 하위 알림을 숨긴다.

inhibit_rules:
  - source_matchers:
      - alertname = RegionUnavailable
    target_matchers:
      - severity = page
    equal:
      - region

region 전체가 내려간 상태라면 그 region의 개별 API, worker, exporter down 알림을 반복해서 보낼 필요가 없다. 다만 억제 규칙이 너무 넓으면 독립적인 두 번째 장애가 숨을 수 있으므로 같은 region, cluster, service 같은 일치 조건을 정확히 둔다.

Silence는 계획된 maintenance나 이미 처리 중인 사건의 알림을 일시적으로 막는다. 영구적인 노이즈를 silence로 덮어서는 안 된다. 종료 시간과 소유자, 이유, 관련 변경을 기록한다.

Missing Data를 정상으로 취급하지 않는다

PromQL 식에서 시계열이 사라지면 결과가 빈 벡터가 될 수 있다. 알림 조건이 error_ratio > 2%라면 metric 수집 자체가 중단된 상황에서 아무것도 firing하지 않을 수 있다.

service down
→ /metrics scrape 실패
→ error metric 없음
→ error ratio alert 결과도 없음
→ 조용함

그래서 다음을 별도로 본다.

up{job="article-api"} == 0

그러나 개별 인스턴스 한 대의 up == 0을 모두 page로 보내면 자동 복구 가능한 교체까지 사람을 부른다. 서비스 전체 capacity와 replica 비율로 집계하거나, black-box 요청 실패와 연결한다.

(
  sum(up{job="article-api"})
  /
  count(up{job="article-api"})
) < 0.5

metric이 멈췄지만 up은 살아 있는 경우도 있다. 마지막 이벤트 시각 또는 expected heartbeat를 기록한다.

time() - max(article_index_last_success_timestamp_seconds) > 900

주기 작업이 10분마다 실행된다면 15분 이상 성공 시각이 갱신되지 않을 때 경고하는 개념이다. 실행 주기, 최대 지연, 휴일 일정에 맞춰 임곗값을 정한다.

재구성한 Prometheus 알림 규칙 예제

다음은 특정 운영 환경의 실제 규칙을 복사한 것이 아니라, 99.9% availability SLO를 가진 API를 가정한 예시다.

먼저 good event와 valid event로 SLI recording rule을 만든다.

groups:
  - name: article-api-sli
    interval: 30s
    rules:
      - record: article_api:valid_requests:rate5m
        expr: |
          sum(
            rate(
              http_server_requests_total{
                service="article-api",
                traffic_class="external",
                status_class!~"3xx|4xx"
              }[5m]
            )
          )

      - record: article_api:bad_requests:rate5m
        expr: |
          sum(
            rate(
              http_server_requests_total{
                service="article-api",
                traffic_class="external",
                status_class="5xx"
              }[5m]
            )
          )

실제 availability 정의에서 어떤 4xx, timeout, gateway 오류를 분모와 분자에 포함할지는 서비스 계약에 따라 달라진다. 서버 metric만 쓰면 gateway에서 실패한 요청을 놓칠 수 있으므로 사용자에게 가까운 측정점을 검토한다.

Burn rate 식을 recording rule로 재사용한다.

      - record: article_api:error_ratio:rate5m
        expr: |
          article_api:bad_requests:rate5m
          /
          article_api:valid_requests:rate5m

      - record: article_api:error_budget_burn:rate5m
        expr: |
          article_api:error_ratio:rate5m
          /
          0.001

1시간과 5분 창을 모두 사용하는 page 규칙은 다음과 같은 형태다.

  - name: article-api-alerts
    interval: 30s
    rules:
      - alert: ArticleApiFastErrorBudgetBurn
        expr: |
          (
            article_api:error_budget_burn:rate1h > 14.4
          )
          and
          (
            article_api:error_budget_burn:rate5m > 14.4
          )
          and
          (
            article_api:valid_requests:increase1h > 1000
          )
        for: 2m
        keep_firing_for: 5m
        labels:
          severity: page
          service: article-api
          slo: external-availability
        annotations:
          summary: "Article API가 error budget을 빠르게 소비하고 있습니다"
          description: "1시간과 5분 burn rate가 모두 14.4배를 넘었습니다."
          runbook_url: "https://docs.example.test/runbooks/article-api-slo"
          dashboard_url: "https://monitoring.example.test/d/article-api"

article_api:error_budget_burn:rate1h와 increase1h도 앞서 같은 방식으로 정의한 recording rule이라고 가정했다. 예제 URL은 모두 가상이다.

완만한 소비는 즉시 page가 아니라 ticket으로 시작할 수도 있다.

      - alert: ArticleApiSlowErrorBudgetBurn
        expr: |
          (
            article_api:error_budget_burn:rate6h > 2
          )
          and
          (
            article_api:error_budget_burn:rate1h > 2
          )
        for: 15m
        labels:
          severity: ticket
          service: article-api

운영 팀이 업무 시간에 처리할 수 있고 즉각적인 개입이 필요 없다면 ticket route로 보낸다. 반대로 2배 burn이 중요한 제품에서는 page가 필요할 수 있다.

규칙은 문법뿐 아니라 시나리오 테스트를 한다.

# promtool 테스트 개념 예제
rule_files:
  - article-api-alerts.yml

evaluation_interval: 1m

tests:
  - interval: 1m
    input_series:
      - series: 'article_api:error_budget_burn:rate1h'
        values: '15x20'
      - series: 'article_api:error_budget_burn:rate5m'
        values: '15x20'
      - series: 'article_api:valid_requests:increase1h'
        values: '5000x20'
    alert_rule_test:
      - eval_time: 5m
        alertname: ArticleApiFastErrorBudgetBurn
        exp_alerts:
          - exp_labels:
              severity: page
              service: article-api
              slo: external-availability

테스트는 최소한 임계값 바로 아래, 짧은 spike, 낮은 표본, no data, 복구와 재발을 포함한다.

알림 메시지에 필요한 정보

사람을 부르는 데 성공했는데 무엇을 봐야 할지 알 수 없다면 탐지 시간만 줄고 복구 시간은 줄지 않는다.

좋은 page에는 다음 정보가 필요하다.

• 무엇이 깨졌는가
• 어느 사용자·지역·기능에 영향이 있는가
• 언제 시작했고 얼마나 지속됐는가
• 현재 값과 기준은 얼마인가
• 어떤 SLO와 연결되는가
• 첫 확인 대시보드와 runbook은 어디인가
• 최근 배포와 변경은 무엇인가
• 소유 팀과 escalation 대상은 누구인가

[PAGE] Article API fast error-budget burn

Impact:
- External availability SLO
- region=ap-northeast

Current:
- 1h burn rate: 18.2x
- 5m burn rate: 24.7x
- valid requests in 1h: 128,420

Started:
- 03:14 KST

Actions:
- Dashboard: ...
- Runbook: ...
- Recent deploys: ...

알림 제목에 원인 추측을 확정적으로 쓰지 않는다.

나쁜 제목: Database overload caused checkout failure
좋은 제목: Checkout success SLO is burning rapidly

원인은 조사 전에는 모를 수 있다. 잘못된 가설이 제목에 있으면 대응자가 그 방향으로 고정될 수 있다.

Runbook에는 확인 순서와 안전한 완화, rollback 조건, 권한과 연락처를 넣는다. 자세한 구성은 장애 대응 Runbook에 들어가야 할 내용에서 이어서 정리한다.

알림 품질을 지표로 관리한다

알림 규칙은 배포 후 끝나는 설정이 아니라 운영 제품이다. 알림마다 실제 결과를 기록한다.

actionable        사람이 실제 조치를 했는가
false positive    사용자 영향이 없었는가
false negative    장애가 있었는데 알림이 없었는가
duplicate         같은 사건의 중복 page였는가
time to acknowledge
time to mitigate

월별로 다음 질문을 확인한다.

• page 중 즉시 행동으로 이어진 비율은 얼마인가
• 자동 복구되어 아무 행동도 하지 않은 page는 무엇인가
• 하나의 incident에 평균 몇 개 page가 왔는가
• 같은 알림이 자주 flapping하는가
• 알림보다 고객 문의가 먼저 온 사건은 무엇인가
• runbook이 없거나 오래된 알림은 무엇인가
• 야간 page와 업무 시간 page의 품질이 다른가

False positive를 0으로 만드는 것도 현실적이지 않다. 너무 둔한 규칙은 실제 장애를 놓친다. 목표는 오류 없는 예측이 아니라 page가 왔을 때 신뢰하고 즉시 행동할 수 있는 신호 대 잡음 비율이다.

기존 알림을 정리하는 절차

알람 피로가 이미 심하다면 모든 임곗값을 한꺼번에 높이지 않는다. 다음 순서로 인벤토리를 만든다.

1. 최근 30~90일의 Page를 모은다

alert name
fired count
incident count
action taken
time to resolve
false positive reason
owner
runbook

2. 행동 기준으로 분류한다

3. 가장 시끄러운 규칙부터 고친다

전체 page의 대부분을 만드는 소수 규칙이 있는 경우가 많다. frequency와 야간 방해 시간을 기준으로 우선순위를 정한다.

4. Shadow 평가를 한다

새 규칙을 notification 없이 일정 기간 평가해 기존 incident를 잡는지, 얼마나 자주 firing하는지 본다.

labels:
  severity: shadow

5. 장애 시나리오로 검증한다

• 100% 오류 5분
• 3% 오류 2시간
• 트래픽 0
• 표본 10건 중 오류 1건
• 배포 중 인스턴스 절반 교체
• metric 수집 중단
• region 전체 장애

각 시나리오에서 언제 어떤 알림 한 개가 누구에게 전달되는지 예상한다.

6. 변경 후 회고한다

새 임곗값 때문에 탐지가 늦어지지 않았는지, 중복 알림이 줄었는지, 실제 행동률이 올랐는지 본다. 규칙 변경 자체도 version control과 review 대상이다.

마무리

알람 피로를 줄인다는 것은 임곗값을 무조건 높이거나 알림을 끄는 일이 아니다. 시스템이 사람에게 판단을 떠넘기는 지점을 줄이는 일이다.

Page는 사용자 영향이 있고 사람이 지금 행동하면 결과가 달라지는 사건에만 사용한다. 나머지는 ticket, dashboard, log, 자동화로 보낸다.

임곗값을 설계할 때는 다음 기준을 함께 둔다.

1. 사용자 증상과 SLO에서 시작한다.
2. 비율은 절대 건수와 최소 표본 조건을 함께 본다.
3. for와 해제 완충으로 짧은 spike와 flapping을 줄인다.
4. 빠른 장애와 느린 장애에 서로 다른 시간 창을 사용한다.
5. error budget burn rate로 서로 다른 SLO를 같은 의미로 비교한다.
6. 서비스와 지역 단위로 그룹화하고 상위 장애가 하위 알림을 억제하게 한다.
7. no data와 monitoring failure를 별도로 탐지한다.
8. 모든 page에 owner, dashboard, runbook, 첫 행동을 연결한다.
9. firing 횟수가 아니라 실제 행동률과 incident 기여도로 품질을 평가한다.
10. 알림 규칙과 테스트를 코드로 version control한다.

좋은 알림 시스템은 모든 이상을 알려 주는 시스템이 아니다. 놓치면 안 되는 사건을 적은 수의 신뢰할 수 있는 신호로 전달하고, 대응자가 곧바로 안전한 행동을 시작할 수 있게 하는 시스템이다.

참고 자료

• Prometheus - Alerting rules
• Google SRE Workbook - Alerting on SLOs
• Google SRE Book - Monitoring Distributed Systems
• Google SRE Book - Production Services Best Practices

관련 노트

• 운영 지표에서 평균보다 백분위수를 보는 이유
• RED Method로 API 모니터링 시작하기
• 분산 추적에서 Trace ID와 Span ID 역할
• 장애 대응 Runbook에 들어가야 할 내용
• 백업이 아니라 복구를 테스트해야 하는 이유
• RPO와 RTO로 복구 목표 정하기